Normal quality testing procedures for software applications involve execution of regression tests. Regression tests represent a set of tests that are executed with each release of a product, often multiple times prior to product release. These tests typically are automated for efficiency. Results of the tests are saved in files on the disk. An initial set of these files is manually inspected (e.g., by quality assurance personnel) for accuracy and form a “baseline” set of results. Subsequent runs of tests are executed and generate another set of results. The new set of results is compared against the baseline to ensure that product functionality is as expected and that no functionality has regressed.
When automated, a regression test typically is a set of instructions either written or recorded for later playback. A handwritten test may be a sequence of instructions in a format that is suitable to the product being tested, such as a set of command-line scripts, or a file fed into a product. A recorded script may be a sequence of keystrokes or mouse movements recorded by a software application specifically designed for such a purpose (e.g., products such as Segue Silk or Mercury WinRunner). Such recorded scripts may be hand-edited to provide for the introduction of variables to simplify multiple test runs with different data. Recorded tests are played back later, and thereby generate output files. The objective is to test the software application to correct any flaws or errors which may be present.
A screen reader is a software application or component that executes on a computer system. A screen reader is provided primarily for those persons who are blind or who have low vision (typically defined as 20/70 vision or worse). Although the term “screen reader” suggests a software program that actually “reads” a computer display, a screen reader does not read characters or text displayed on a computer monitor, but rather interacts with the display engine of a computer or directly with applications to determine what is to be spoken to a user (e.g., via the computer system's speakers).
An example of a screen reader is the JAWS product from Freedom Scientific. It inserts itself as a “display driver”. At that level of the operating system software, it can inspect interaction occurring between the user and the computer, and has access to any information being drawn to the screen. This information is provided by a software application as the software application makes calls to the Operating System. Separately, a screen reader can inspect which windows are currently active, and interrogate them to know what its current active elements are and how they are associated.
With this information, a screen reader determines what is to be spoken to a user. For example, when it sees that a window of an application gains focus, it can announce the window's title. When it sees that a user tabs into a text field in the application, it can indicate audibly to the user that the text field is the center of focus, plus speak an associated label for that text field. A screen reader also has a text-to-speech converter. It can determine what text needs to be spoken, submit it to its text-to-speech converter, and cause audible words to be generated from the computer's audio/speaker system.
Screen readers also interact with Braille displays. A Braille display is a peripheral device that can be attached to a computer (typically a personal computer/PC via its serial port). The Braille display presents a set of lifted pins. This set of pins represents a line of characters that a sighted user would see on the screen at the current point of focus.
A Braille display provides input devices for moving the focus on the computer, typically allowing a user to scroll through or across a larger information set, since the display itself is limited to a small number of characters and lines. For example, a 1 line high×40 character wide Braille display only captures a small portion of a typical 24×80 terminal window, and one such window is a small portion of what a sighted user can see on a high resolution computer screen.
The characters on a Braille display represent characters that can be represented on a computer keyboard, including alphanumerics, upper and lower case, and punctuation. There also is a pin representation for the current text insertion point, which corresponds to what sighted users would see as a blinking cursor. Braille displays are “driven” by a screen reader or similar technology that knows what commands to send such that the display shows the right text and the right cursor position.
Thus, applications that interact with screen readers comprise sophisticated software programming that must be updated periodically to accommodate new features, new computer system hardware, new user requirements, and the like. In addition to updates, applications often have flaws or bugs which must be fixed with successive product releases. Thus there exists great interest in applying software test methodologies to applications in an environment that includes screen readers.
The need for an efficient test system for applications interacting with screen reading technology also stems from recent government demands to provide software the is coded to Section 508 standards. In 1973, the United States legislature passed the Workforce Rehabilitation Act. On Aug. 7, 1998, an amendment to the workforce rehabilitation act, commonly referred to as “Section 508”, was signed into law by President Clinton. Section 508 requires that electronic and information technology developed or purchased by the Federal Government be accessible to people with disabilities. Section 508 establishes both non-binding guidelines for technology accessibility and binding, enforceable standards that will be incorporated into the Federal Procurement procedures. In addition to providing for enforceable standards, the amended Section 508 establishes a complaint procedure and reporting requirements to encourage compliance.
While software products can be coded to meet Section 508 standards, it is currently a time consuming, manual and audible process to test that an application is functional using a screen reader. The manual part of repeating such a test can be recorded through prior art regression testing software as described above, but playback would yield audible results that would need human interpretation and verification over time. Because of this, regression testing of large scale screen reader applications becomes untenable, causing high organizational cost.
Thus, what is required is an automated regression testing system that can function with applications and screen reader software. Additionally, what is required is an automated regression testing system compatible with the audible results of a screen reader. The present invention provides a novel solution to the above requirements.